index.html (1)

65-69: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

"Reset to 100%" label/tooltip mismatches actual "fit stage" behavior.

state.viewZoom = 1 is documented in app.js as "program-monitor display zoom (1 = fit stage)", i.e., it's a fit-to-stage baseline, not a literal native-pixel 100% zoom. Labeling the button "Reset to 100%" (and tooltip "Reset monitor zoom to fit (100%)") conflates these two concepts and may confuse users who expect true 1:1 pixel scale.

✏️ Suggested wording

-          <button class="btn tiny hidden" id="btnZoom100" title="Reset monitor zoom to fit (100%)">...Reset to 100%</button>
+          <button class="btn tiny hidden" id="btnZoom100" title="Reset monitor zoom to fit">...Reset zoom</button>

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@index.html` around lines 65 - 69, Update the Program Monitor reset button
identified by btnZoom100 so its visible label and title describe restoring the
fit-to-stage baseline rather than “100%” or native-pixel zoom; keep the existing
reset behavior unchanged.

app.js (2)

4430-4457: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

No bounds on state.viewPan.

Neither the wheel-zoom pan adjustment nor the drag-pan pointermove handler clamps state.viewPan, so a user can drag the zoomed canvas entirely out of the visible stage. Recovery only via the "Reset to 100%" button, which is a usable fallback but still a rough edge.

🔧 Suggested clamp using existing bounding-rect data

 function applyMonitorView() {
   const z = state.viewZoom, pan = state.viewPan;
   const zoomed = z > 1.001;
   if (!zoomed) {
     state.viewZoom = 1;
     state.viewPan = { x: 0, y: 0 };
     els.preview.style.transform = "";
   } else {
+    const stage = els.monitorStage.getBoundingClientRect();
+    const maxX = (stage.width * (z - 1)) / 2;
+    const maxY = (stage.height * (z - 1)) / 2;
+    pan.x = clamp(pan.x, -maxX, maxX);
+    pan.y = clamp(pan.y, -maxY, maxY);
     els.preview.style.transform = `translate(${pan.x}px, ${pan.y}px) scale(${z})`;
   }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app.js` around lines 4430 - 4457, Clamp state.viewPan to valid bounds after
both the wheel-zoom adjustment and drag-pan updates so the zoomed canvas cannot
be moved entirely outside the visible stage. Reuse the existing monitor stage
and content bounding-rect data where available, and apply the clamp before
applyMonitorView() in the pointermove path and before storing the zoom-adjusted
pan.

---

4398-4457: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

updateSafeOverlay() forces layout on every wheel tick and pan pointermove.

applyMonitorView() calls updateSafeOverlay() (two getBoundingClientRect() reads) right after mutating els.preview.style.transform, and this runs on every wheel event and every pointermove while panning (when state.guides is on). That's a write-then-read cycle repeated at high frequency, forcing synchronous layout each time and risking visible jank during zoom/pan.

⚡ Suggested throttling via requestAnimationFrame

+let viewRafPending = false;
+function scheduleApplyMonitorView() {
+  if (viewRafPending) return;
+  viewRafPending = true;
+  requestAnimationFrame(() => { viewRafPending = false; applyMonitorView(); });
+}

Then call scheduleApplyMonitorView() from the wheel and pointermove handlers instead of applyMonitorView() directly (transform mutation itself can stay immediate if desired; the goal is to coalesce the updateSafeOverlay reflow to once per frame).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app.js` around lines 4398 - 4457, Throttle monitor view updates with
requestAnimationFrame: add a scheduling helper around applyMonitorView that
coalesces repeated calls into one frame, and use it from the wheel and
pointermove handlers instead of calling applyMonitorView directly. Preserve
immediate reset behavior for resetMonitorView and ensure updateSafeOverlay runs
at most once per animation frame during zooming and panning.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes